malformed input file can hang flex

[hannob]

The attached file will hang flex, probably causing it to be stuck in an infinite loop. It's only one line, so it can also easily be tested on the command line:

echo '%option 8bit prefix="yywrap%"' | flex

This was found with the fuzzing tool american fuzzy lop. Tested with the current git code of flex.
flex-hang.zip

[DemiMarie]

M4 is stuck in a loop because M4_YY_PREFIX expands to yywrap%, but yywrap expands to M4_YY_PREFIX[[wrap]]m4_ifelse($#, 0,,[[($@)]]). Hence there is an infinite loop of recursive macro calls.

Flex should overquote the definition of M4_YY_PREFIX to prevent this from happening, as well as forbidding it from including [ or ]. That would just cause a C syntax error in the generated code anyway.

[DemiMarie]

I wonder if it would be best to rip out the use of M4 from Flex entirely, at least at (Flex) run-time. It has been a giant bug farm (see most of my patches, as well as this bug), is slow (since it involves an extra process), and is not easy to install on Windows. Furthermore, Flex uses very few of M4's features – it uses no recursive macros, for example. M4 is a full Turing-complete programming language, but Flex has no need for this feature.

It would be much cleaner for Flex to handle all templating internally. That would eliminate the need for M4 altogether, except perhaps at build-time (where the problems don't arise).

If we are willing to build-depend on a scripting language (even Awk would work), we could have a script compile the skeleton file into compilable C code that handled the templating itself, with no need for M4.

This would be much easier in C++, due to the C++ Standard Library containers.

[westes]

Getting rid of m4 entirely is definitely an option. I'd prefer that we build a macro processing library if possible rather than switching to another scripting language, though. But lay out what you're thinking in more detail if you like.

…

On Monday, 28 November 2016, 6:24 pm -0800, Demi Marie Obenour ***@***.***> wrote: I wonder if it would be best to rip out the use of M4 from Flex entirely, at least at (Flex) run-time. It has been a giant bug farm (see most of my patches, as well as this bug), is slow (since it involves an extra process), and is not easy to install on Windows. Furthermore, Flex uses very few of M4's features – it uses no recursive macros, for example. If we are willing to build-depend on a scripting language (even Awk would work), we could have a script compile the skeleton file into compilable C code that handled the templating itself, with no need for M4. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #128 (comment)

-- Will Estes westes575@gmail.com

[westes]

This has been fixed on flex master and will be included in the next release of flex.